Technical Field
This disclosure generally relates to distributed data processing systems and to the delivery of content to users over computer networks, and more particularly to techniques for caching content to accelerate content delivery over computer networks.
Brief Description of the Related Art
Distributed computer systems are known in the prior art. One such distributed computer system is a “content delivery network” or “CDN” that is operated and managed by a service provider. The service provider typically provides the content delivery service on behalf of third parties. A “distributed system” of this type typically refers to a collection of autonomous computers linked by a network or networks, together with the software, systems, protocols and techniques designed to facilitate various services, such as content delivery or the support of outsourced site infrastructure. This infrastructure is typically shared by multiple tenants, the content providers. The infrastructure is generally used for the storage, caching, or transmission of content—such as web pages, streaming media and applications—on behalf of such content providers or other tenants. The platform may also provide ancillary technologies used therewith including, without limitation, DNS query handling, provisioning, data monitoring and reporting, content targeting, personalization, and business intelligence.
In a known system such as that shown in FIG. 1, a distributed computer system 100 is configured as a content delivery network (CDN) and has a set of machines 102 distributed around the Internet. Typically, most of the machines are servers located near the edge of the Internet, i.e., at or adjacent end user access networks. A network operations command center (NOCC) 104 may be used to administer and manage operations of the various machines in the system. Third party sites affiliated with content providers, such as web site 106, offload delivery of content (e.g., HTML or other markup language files, embedded page objects, streaming media, software downloads, and the like) to the distributed computer system 100 and, in particular, to the CDN servers (which are sometimes referred to as “edge” servers). Such servers may be grouped together into a point of presence (POP) 107 at a particular geographic location.
The CDN servers are typically located at nodes that are publicly-routable on the Internet, within or adjacent nodes that are located in mobile networks, in or adjacent enterprise-based private networks, or in a combination thereof.
Typically, content providers offload their content delivery by aliasing (e.g., by a DNS CNAME) given content provider domains or sub-domains to domains that are managed by the service provider's authoritative domain name service. The server provider's domain name service directs end user client machines 122 that desire content to the distributed computer system (or more particularly, to one of the CDN serves in the platform) to obtain the content more reliably and efficiently. The CDN servers respond to the client requests, for example by fetching requested content from a local cache, from another CDN server, from the origin server 106 associated with the content provider, or other source.
For cacheable content, CDN servers typically employ a caching model that relies on setting a time-to-live (TTL) for each cacheable object. After it is fetched, the object may be stored locally at a given CDN server until the TTL expires, at which time the object is typically re-validated or re-fetched from the origin server 106. For non-cacheable objects (sometimes referred to as ‘dynamic’ content), the CDN server typically must return to the origin server 106 each time when the object is requested by a client. The CDN may operate a server cache hierarchy to provide intermediate caching of customer content in various CDN servers closer to the CDN server handling a client request than the origin server 106; one such cache hierarchy subsystem is described in U.S. Pat. No. 7,376,716, the disclosure of which is incorporated herein by reference.
Although not shown in detail in FIG. 1, the distributed computer system may also include other infrastructure, such as a distributed data collection system 108 that collects usage and other data from the CDN servers, aggregates that data across a region or set of regions, and passes that data to other back-end systems 110, 112, 114 and 116 to facilitate monitoring, logging, alerts, billing, management and other operational and administrative functions. Distributed network agents 118 monitor the network as well as the server loads and provide network, traffic and load data to a DNS query handling mechanism 115. A distributed data transport mechanism 120 may be used to distribute control information (e.g., metadata to manage content, to facilitate load balancing, and the like) to the CDN servers. The CDN may include a network storage subsystem (sometimes referred to herein as “NetStorage”) which may be located in a network datacenter accessible to the CDN servers and which may act as a source of content, such as described in U.S. Pat. No. 7,472,178, the disclosure of which is incorporated herein by reference.
As illustrated in FIG. 2, a given machine 200 in the CDN comprises commodity hardware (e.g., a microprocessor) 202 running an operating system kernel (such as Linux or variant) 204 that supports one or more applications 206. To facilitate content delivery services, for example, given machines typically run a set of applications, such as an (hypertext transfer protocol) HTTP proxy 207, a name server 208, a local monitoring process 210, a distributed data collection process 212, and the like. The HTTP proxy 207 (sometimes referred to herein as a global host or “ghost”) typically includes a manager process for managing a cache and delivery of content from the machine. For streaming media, the machine may include one or more media servers, such as a Windows Media Server (WMS) or Flash server, as required by the supported media formats.
A given CDN server shown in FIG. 2 may be configured to provide one or more extended content delivery features, preferably on a domain-specific, content-provider-specific basis, preferably using configuration files that are distributed to the CDN servers using a configuration system. A given configuration file preferably is XML-based (extensible markup language-based) and includes a set of content handling rules and directives that facilitate one or more advanced content handling features. The configuration file may be delivered to the CDN server via the data transport mechanism. U.S. Pat. No. 7,240,100, the contents of which are hereby incorporated by reference, describe a useful infrastructure for delivering and managing CDN server content control information and this and other control information (sometimes referred to as “metadata”) can be provisioned by the CDN service provider itself, or (via an extranet or the like) the content provider customer who operates the origin server. U.S. Pat. No. 7,111,057, incorporated herein by reference, describes an architecture for purging content from the CDN machines. More information about a CDN platform can be found in U.S. Pat. Nos. 6,108,703 and 7,596,619, the teachings of which are hereby incorporated by reference in their entirety.
In a typical operation, a content provider identifies a content provider domain or sub-domain that it desires to have served by the CDN. The CDN service provider associates (e.g., via a canonical name or CNAME, or other aliasing technique) the content provider domain with a CDN hostname, and the CDN provider then provides that CDN hostname to the content provider. When a DNS query to the content provider domain or sub-domain is received at the content provider's domain name servers, those servers respond by returning the CDN hostname. That network hostname points to the CDN, and that hostname is then resolved through the CDN name service. To that end, the CDN name service returns one or more IP addresses. The requesting client application (e.g., browser) then makes a content request (e.g., via HTTP or HTTPS) to a CDN server machine associated with the IP address. The request includes a host header that includes the original content provider domain or sub-domain. Upon receipt of the request with the host header, the CDN server checks its configuration file to determine whether the content domain or sub-domain requested is actually being handled by the CDN. If so, the CDN server applies its content handling rules and directives for that domain or sub-domain as specified in the configuration. These content handling rules and directives may be located within an XML-based “metadata” configuration file, as noted above.
The CDN platform may be considered as an overlay across the Internet on which communication efficiency can be improved. Improved communications on the overlay can help when a CDN server needs to obtain requested content from an origin server 106 or from another CDN server that is acting as an intermediate cache-parent, or when accelerating communication of non-cacheable content across the overlay on behalf of a content provider, or otherwise. Communications between CDN servers and/or across the overlay may be enhanced or improved using route selection, protocol optimizations including TCP enhancements, persistent connection pooling and reuse, content & header compression and de-duplication, and other techniques such as those described in U.S. Pat. Nos. 6,820,133, 7,274,658, 7,607,062, and 7,660,296, among others, the disclosures of which are incorporated herein by reference.
As an overlay offering communication enhancements and acceleration, the CDN server resources may be used to facilitate wide area network (WAN) acceleration services between enterprise data centers and/or between branch-headquarter offices (which may be privately managed), as well as to/from third party software-as-a-service (SaaS) providers used by the enterprise users.
Along these lines, CDN customers may subscribe to a “behind the firewall” managed service product to accelerate Intranet web applications that are hosted behind the customer's enterprise firewall, as well as to accelerate web applications that bridge between their users behind the firewall to an application hosted in the internet cloud (e.g., from a SaaS provider).
To accomplish these two use cases, CDN software may execute on machines (potentially in virtual machines running on customer hardware) hosted in one or more customer data centers, and on machines hosted in remote “branch offices.” The CDN software executing in the customer data center typically provides service configuration, service management, service reporting, remote management access, customer SSL certificate management, as well as other functions for configured web applications. The software executing in the branch offices provides last mile web acceleration for users located there. The CDN itself typically provides CDN hardware hosted in CDN data centers to provide a gateway between the nodes running behind the customer firewall and the CDN service provider's other infrastructure (e.g., network and operations facilities). This type of managed solution provides an enterprise with the opportunity to take advantage of CDN technologies with respect to their company's intranet, providing a wide-area-network optimization solution. This kind of solution extends acceleration for the enterprise to applications served anywhere on the Internet. By bridging an enterprise's CDN-based private overlay network with the existing CDN public internet overlay network, an end user at a remote branch office obtains an accelerated application end-to-end. FIG. 3 illustrates a general architecture for a WAN optimized, “behind-the-firewall” service offering such as that described above, along with examples of possible data flows across the overlay. Other information about a behind the firewall service offering can be found in teachings of U.S. Pat. No. 7,600,025, the teachings of which are hereby incorporated by reference.
While known techniques, such as those currently used in CDNs, offer many advantages, there is a need for techniques to better accelerate traffic for which a no-store or explicit-TTL caching approach is suboptimal, which is an increasing and important part of the traffic on the Internet. Content accessed through application programmer interfaces (API) are one example of such traffic. With the foregoing by way of introduction, the improved systems, methods, and apparatus that are the subject of this disclosure are described below.